The present invention relates to a method and system for confirming the correct operation of a computer program that is to be executed on a computer system (the "target system" or "remote system") that is different than the computer system on which the application code is being developed (the "host system" or "development system").
Several well-known methods for developing and verifying the correct operation of target system programs currently exist. One popular method is to create a software simulation of the target system to simulate the input/output (I/O) process through use of computer graphics, printed output, or other means. This method has two primary disadvantages: 1) the simulation of the target system my have inherent errors or inaccuracies and thus may not properly indicate the behavior of the target system and 2) the simulation program requires significant programing effort to generate and validate. Additionally, such simulation programs are generally cumbersome, are frequently application-dependent and usually require a significant amount of storage.
Another popular method of developing target system applications is though use of a processor or Central Processing Unit Emulator ("CPU Emulator"). This method requires that the CPU for the target system be replaced during the development phase with a device that emulates the functions of the CPU. Although such a system may provide an application program developer with the ability to examine the internal status of the CPU and to control extensively the operations of the CPU, such emulation systems are physically large, expensive and often require special or application-specific hardware and software. Frequently, special adapters and wiring harnesses are also required to attach the emulators to the target systems.
A further well-known method of debugging target system applications is by the use of software debuggers such as Microsoft's CodeView.RTM. and Borland's Turbo Debugger.RTM. in the IBM PC.RTM. compatible development environments. When the application is being designed to run on an IBM PC, these debugging programs enable the developer to control the execution of the program and provide information to the developer about internal program states. This debugging method requires that the target system be IBM PC compatible, DOS operating system compatible and that the target system include compatible video display, keyboard, and disk system hardware and software. For many target system applications, the need to provide extra hardware and software for merely debugging purposes renders such an approach economically infeasible.
In many prior art development environments, the application program is down-loaded to and stored on the target system after it is determined through one of the above prior art methods that the application program is functioning at some acceptable level of accuracy or efficiency. When the application program is to be down-loaded, the program instructions are typically generated using prior art methods by a compiler or assembler with relative address references for both code and data. In most prior art systems, the problem of locating the instructions on the target system is resolved through use of a table of values to "fix up" or convert the address references to references required by the target system. Such a "relocation table" is generated in compilers and assemblers in conjunction with the generation of executable instructions. This approach, however, requires that all addresses or locations be resolved to a specific location before the program can be run.
In prior art systems, addresses are, more specifically, resolved in one of two primary ways:
1) by having the target system compute the next available address and perform address resolution before the program is run, or PA0 2) by providing specific memory resolution information for the target system before loading the application into the target system.
The first method is widely used in many popular computing environments such as the IBM PC but has the drawback of requiring that the target system have the relocation table in memory to perform the required address resolution.
The second approach is typically used in relocating an application designed for small operating systems. Under this second method, relocation decisions are made manually at program build time, and the relocation is performed with the presumption that the program may occupy a fixed address in the target system without conflict. This method is adequate for single application environments, but when the method is extended to target systems capable of running multiple applications, difficulties arise. If one or more applications are loaded onto the target system, the relocation must be performed manually before each program load to avoid overwriting the data or code space of the other applications. Therefore, this method is cumbersome, error prone, and inappropriate for loading applications designed to operate on target systems in the field.